1. Field of the Invention
The present invention relates to a method of storing broadcast contents in a mobile terminal supporting broadcast services, and more particularly to a method of recording and storing broadcast contents received through mobile broadcast services in a transmitting-end level.
2. Description of the Related Art
The mobile communication market constantly faces a demand for new service created through recombination or integration of the existing technologies. Today, due to the development of communication and broadcast technologies, conventional broadcast systems or mobile communication systems has reached the phase of providing mobile broadcast services to a mobile terminal, such as a mobile phone and a Personal Digital Assistant (PDA). Fusion of mobile communication services and the Internet Protocol (IP) technologies is now one of the mainstreams of next generation mobile communication technology development in harmony with potential and substantial market demand, users' increasing need for multimedia services, strategies of service providers desiring to provide new services in addition to the existing voice services, and the interest of Internet Technology (IT) companies reinforcing mobile communication business to meet the users' needs. In addition, commercialization and standardization for mobile broadcast services provided to mobile terminals are actively conducted.
As an example of the standardization, Open Mobile Alliance (OMA) is responsible for discussing and establishing standards of international mobile communication technologies defining the mobile broadcast technology standard. The mobile broadcast technology standard, which is referred to as Open Mobile Alliance Mobile Broadcast (OMA-BCAST), defines various methods of providing mobile broadcast services over a mobile broadcast network. Further, the OMA-BCAST also defines a Service and Content Protection (SCP) standard in order to protect broadcast contents for the mobile broadcast services. In the OMA-BCAST SCP, an encryption technology using a layering concept is defined, in which the broadcast contents are encrypted with a specific key allowing only authorized users to record, store, and transmit the broadcast contents.
FIG. 1 illustrates the layers defined in the OMA-BCAST SCP. Referring to FIG. 1, a first layer (Layer 1) 110 is responsible for registering services in a mobile broadcast receiving terminal (hereinafter referred to as receiving terminal) supporting mobile broadcast services. When the receiving terminal registers a service, the first layer 110 provides a Right Encryption Key (REK) or a Subscribe Manager Key (SMK) as a first layer encryption key. A second layer (Layer 2) 120 transmits an encryption key, which is retained during a period time of service subscription or program transmission. A second layer encryption key is classified into a Service Encryption Key (SEK) and a Program Encryption Key (PEK) according to the type of the encryption key. The SEK or PEK is used to encrypt/decrypt a Traffic Encryption Key (TEK), which is an encryption key of a third layer (Layer 3) 130. The third layer 130 uses the TEK as the third layer encryption key in order to encrypt/decrypt a broadcast content transmitted to the mobile broadcast service. The TEK, together with the broadcast content, is transmitted over a typical broadcast network, and is frequently changed because of the risk of hacking. In a fourth layer 140, the actual broadcast content is transmitted, and the third layer encryption key TEK is used as an decryption key for decrypting the encrypted program and content.
In the layered structure described above, since the TEK transmitted is encrypted with the second layer encryption key SEK or PEK, only receiving terminals having the SEK or PEK capable of decrypting the TEK of the third layer can obtain the right TEK, by which the broadcast content transmitted from the fourth layer (Layer 4) 140 can be decrypted.
In the fourth layer 140, various protocols may be used for broadcast content protection. In the OMA-BCAST SCP, protocols for protecting the broadcast content in the fourth layer 140 include a Secure Real Time Protocol (SRTP), an IP Security Protocol (IPSec), an Internet Streaming Media Alliance Crypto Protocol (ISMACryp), and a DRM Content Format (DCF) protocol. The SRTP and IPSec are used to protect contents by performing encryption at the broadcast transmitting-end, and the ISMACryp and DCF are used to encrypt the contents themselves.
The OMA-BCAST SCP may be classified into two profiles according to the encryption key management schemes: a DRM profile employing the standardized Digital Right Management (OMA-DRM) scheme and a smartcard profile employing a standardized encryption key management scheme included in a smartcard of a terminal. Therefore, only the receiving terminals having a DRM engine or a smartcard corresponding to a protocol being used can record and store broadcast contents received through the mobile broadcast service.
In the OMA-BCAST SCP, since broadcast contents received through a broadcast network or a communication network are recorded and stored in the receiving terminal after being encrypted, only particular users can use the recorded broadcast contents which are encrypted. Further, by defining a format for encrypting and storing broadcast contents, recorded files for encrypted broadcast contents can be shared by multiple terminals.
FIG. 2 illustrates terminals storing and sharing a broadcast content of the OMA-BCAST SCP. Referring to FIG. 2, terminal A 201 and terminal B 203 are authorized to use a particular broadcast content, and terminal C 205 is not authorized to use the particular broadcast content. In general, terminals may be authorized to use particular broadcast contents by being provided with the encryption keys from the mobile broadcast systems providing mobile broadcast services.
Terminal A 201 records and stores the particular broadcast content over a broadcast network or a communication network after encrypting it. Thereafter, terminal A 201 transmits a recorded file 207 for the particular broadcast content to terminal B 203 and terminal C 205. At this time, the recorded file 207 may be transmitted to terminal B 203 and terminal C 205 through a memory card or a network.
Since terminal B 203 has been authorized to use the particular broadcast content, it can obtain the encryption key, which has been used for encrypting in terminal A 201 from the mobile broadcast system. Therefore, the recorded file, which has been encrypted by using the encryption key, can be decrypted and reproduced in terminal B 203.
However, since terminal C 205 is not authorized to use the particular broadcast content, it cannot obtain the encryption key for reproducing the recorded file for the encrypted broadcast content received from terminal A 201. Therefore, the recorded file received from terminal A 201 cannot be reproduced in terminal C 205. If a user of terminal C 205 desires to reproduce the recorded file received from terminal A 201, the user has to obtain a right (right object) to reproduce the recorded file on the user's mobile broadcast system. For obtaining the authorization to use or the right object, acquisition information on the encryption key is included in the recorded file.
In the OMA-BCAST SCP, formats regarding broadcast content recording are defined in two types: a Packetized DRM Content Format (PDCF) and an Adapted-PDCF. In the PDCF, encrypted broadcast contents transmitted at the broadcast transmitting-end are re-encrypted, recorded and stored. The PDCF is used to store broadcast media contents, which are transmitted by being encrypted with the SRTP and IPSec. The Adapted-PDCF is used to store broadcast contents in a case where they are transmitted by being encrypted with the ISMACryp. The PDCF and Adapted-PDCF are defined pursuant to “DRMContent Format” (DCF standard) and “DRM v2.0 Extensions for Broadcast Support” (XBS standard) established by OMA, respectively.
There are two schemes by which the encrypted broadcast contents are generated and stored. Specifically, in order to record broadcast contents, which are transmitted by being encrypted at the transmitting-end using the IPSec and SRTP, broadcast contents are recorded and stored in the PDCF, which is referred to as a transmitting-end level recording scheme. Further, in order to record and store broadcast contents which are transmitted by being encrypted using the ISMACryp, broadcast contents are recorded and stored in the Adapted-PDCF, which is referred to as a content level recording scheme.
However, only receiving terminals supporting the DRM profile of the OMA-BCAST can record broadcast contents in the PDCF. Therefore, in a case where broadcast contents are transmitted by using the transmitting-end encryption protocol, such as IPSec and SRTP, receiving terminals only supporting smartcard profile cannot store broadcast contents in the PDCF.
When broadcast contents are recorded in the PDCF, a receiving terminal supporting the DRM profile generates a Content Item Encryption Key (CIEK) by using a provided DRM engine and encrypts broadcast contents. Thereafter, the receiving terminal encrypts the CIEK with the SEK or PEK. At this time, acquisition information on the SEK or PEK is included in a header of the PDCF file. That is, identification information on the used SEK or PEK and address information on a server providing the SEK or PEK is included in the header of the PDCF file.
Then, the receiving terminal transmits the PDCF file, in which broadcast contents are recorded and stored, to other receiving terminals. The other receiving terminals received the PDCF file obtain the SEK or PEK by using the identification information on the SEK or PEK and the address information on a mobile broadcast system providing the SEK or PEK which are included in the header of the received PDCF file, or purchase the SEK or PEK through the DRM engine. Thereafter, the other receiving terminals can reproduce broadcast contents by decrypting the PDCF file.
However, since receiving terminals supporting a smartcard profile cannot generate acquisition information on the SEK or PEK, which has been used in recording and storing broadcast contents in the PDCF and cannot include the SEK or PEK in the PDCF file, receiving terminals supporting a smartcard profile cannot share the PDCF file with other terminals, nor generate it. Therefore, there is a need for enabling the receiving terminals supporting a smartcard profile to record and store broadcast contents in the transmitting-end level.